前幾天從「重新處理」按鈕，談到批次操作與排隊期間的狀態變化，需要照顧的地方越來越多。

今天先往回看：營運人員原本的困難，是訂單呼叫庫存服務逾時後，無法確認結果，只能等工程師協助。如果系統能查明結果，並安全地接續處理，還需要由人按下按鈕才開始嗎？

先確認自動恢復的條件

假設庫存服務能用固定的操作識別查詢扣減結果，重複收到同一筆操作時，也能避免再次扣減，系統就可能在逾時後自動恢復。有了這兩項能力，背景工作就能先查詢結果：已扣減，就同步訂單狀態；仍在處理，就稍後再查；符合補送條件時，才沿用原識別重試。

「查不到」也不能直接當成「沒扣」。原請求可能還在執行，查詢資料也可能尚未同步，要依服務契約判斷。結果未明就保留待確認；訂單已取消或不再符合條件，也不能照原樣繼續扣減。

人工操作還剩下什麼？

如果多數逾時都能在可接受的時間內恢復，營運人員可能只需要看處理進度，以及哪些訂單仍需關注。原本的批次勾選、全選與確認送出，就不一定都要做。

超過約定時間仍查不明的訂單，則需要呈現已有證據，交由人員核對，再決定下一步。多放一顆「重試」按鈕，並不會讓未知的結果變得已知。

人工入口也必須遵守相同的處理條件與防重規則，避免背景工作與人員同時操作，造成重複扣減。

把效益和代價一起算

不過，現有庫存服務也可能沒有上述能力。要補上查詢與防重機制，還得協調另一個團隊排程。自動化值得考慮，但不一定是現在最適合的投入。

我會整理技術條件與預估工作，和團隊比較：

假設一個月只有兩筆異常，每筆核對五分鐘，也不影響出貨，維持現況可能足夠。若一天六十筆，同樣每筆五分鐘，就是每天五小時的人工作業，還沒算等待與交接。

實際討論要依據事件紀錄與處理時間，也要看延誤的影響。有些異常一次就可能耽誤出貨，不能只看平均工時。

自動恢復也有持續成本。服務故障時，重試需要限制速率與次數，超過處理期限要能告警並交接。按鈕少了，這些工作仍然要有人維護。

團隊可以先列清楚待確認訂單，再加入安全的自動恢復。若暫緩，也要約定異常量、等待時間或作業影響達到什麼門檻時，重新評估。

AI很快做出來之後，還要看什麼？

回到這個例子，假設我們提供完整規格，讓AI沿用專案既有模式完成批次按鈕、API與測試。看著畫面能操作、測試全綠，很容易覺得：「都做好了，就上吧。」但這些成果還沒回答：營運人員以後是不是仍要每天進來勾選？

同樣的AI，也能在實作前追查現有的結果查詢、防重機制與背景工作，比較「人工觸發」與「自動恢復」各要補哪些能力；若再拿到實際的異常紀錄，還能估算哪些訂單可以自動處理、哪些仍需人工判斷。差別在於交給它的問題，是「把按鈕做出來」，還是「讓營運人員不必再等工程師」。

功能做得越快，越容易跳過「要不要做」這一步。值不值得做，要把上線後的維護與營運一起算進去；有時調整流程就已足夠，不必再多一顆按鈕。

去年AI正火熱的時候，老闆也想了不少LLM可能派得上用場的功能
討論時很有畫面：AI先理解Dashboard的情況，自動決定下一步。聽起來終於要輪到我們做點有AI味的東西了

結果把情境一個個攤開，確認輸入、判斷條件是什麼、每種情況要做什麼之後，規則越來越明確，留給LLM發揮的空間也越來越小。

最後發現，這次要解決的問題，用幾個if else就夠了。
功能有完成，問題也有改善，整個過程中，最有AI含量的部分，是我請AI把那幾個if else寫出來